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A Naming Scheme for c=US 
Status of this Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard. Distribution of this memo is 
unlimited. 


Summary 


This RFC is a near-verbatim copy of a document, known as NADF-175, 
which has been produced by the North American Directory Forum (NADF). 
The NADF is a collection of organizations which offer, or plan to 
offer, public Directory services in North America, based on the CCITT 
X.500 Recommendations. As a part of its charter, the NADF must reach 
agreement as to how entries are named in the public portions of the 
North American Directory. NADF-175 represents the NADF’s agreement 
in this area. 
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July 12, 1991 


1. Introduction 


Computer networks form the infrastructure between the users they 
interconnect, and networks are built on an underlying naming and 
numbering infrastructure, usually in the form of names and addresses. 
For example, some authority must exist to assign network addresses to 
ensure that numbering collisions do not occur. This is of paramount 
importance for an environment which consists of multiple service 
providers. 


2. Approach 


It should be observed that there are several different naming 
universes that could be used in the Directory Information Tree (DIT). 
For example, geographical naming, community naming, political naming, 
organizational naming, and so on. The choice of naming universe 
largely determines the difficulty in mapping a user’s query into a 
series of Directory operations to find useful information. Although 
it is possible to simultaneously support multiple naming universes 
with the DIT, this is likely to be unnatural. As such, this scheme 
focuses on a single naming universe. 


The naming universe in this scheme is based on civil authority. That 
is, it uses the existing civil naming infrastructure and suggests a 
(nearly) straight-forward mapping on the DIT. An important 
characteristic is that entries can be listed wherever searches for 
them are likely to occur. This implies that a single object may be 
listed as several separate entries. 
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2.1. Names and User-Friendliness 


It must be emphasized that there are two distinct concepts which are 
often confused when discussing a naming scheme: 


(1) user-friendly naming: 
a property of a Directory which allows users to easily 
identity objects of interest; and, 


(2) Distinguished Name: 
the administratively assigned name for an entry in the 
OSI Directory. 


It must be emphasized that Distinguished Names are not necessarily 
user-friendly names, and further, that user-friendly naming in the 
Directory is a property of the Directory Service, not of 
Distinguished Names. 


2.2. Choice of RDN Names 


The key aspect to appreciate for choice of RDNs is that they should 
provide a large name space to avoid collisions: the naming strategy 
must provide enough "real estate" to accommodate a large demand for 
Distinguished Names. This is the primary requirement for RDNs. A 
secondary requirement is that RDNs should be meaningful (friendly to 
people) and should not impede searching. 


However, it is important to understand that this second requirement 
can be achieved by using additional (non- distinguished) attribute 
values. For example, if the RDN of an entry is 


organizationName is Performance Systems International 


then it is perfectly acceptable (and indeed desirable) to have other 
values for the "organizationName" attribute, e.g., 


organizationName is PSI 


The use of these abbreviated names greatly aids searching whilst 
avoiding unnecessary Distinguished Name conflicts. 


In order to appreciate the naming scheme which follows, it is 
important to understand that wherever possible it leverages existing 
naming infrastructure. That is, it relies heavily on non-OSI naming 
authorities which already exist. Note that inasmuch as it relies on 
existing naming authorities, there is little chance that any "final" 
national decision could obsolete this scheme. (Any naming scheme may 
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be subject to the jurisdiction of certain national agencies. For 
example, the US State Department is concerned with any impact on US 
telecommunications treaty obligations.) To do so would require a 
national decision that disregards existing national and regional 
infrastructure, and establishes some entirely new and different 
national naming infrastructure. 


2.3. Outline of the Scheme 
The naming scheme is divided into four parts: 


(1) a discussion of the right-to-use, registration, and 
publication concepts; 


(2) a discussion of objects with national, regional, local, 
and foreign standing; 


(3) a discussion of objects which may be listed at 
national, regional, and local levels; and, 


(4) a discussion of how RDNs are formed for listing entries 
at each different level. 


3. The Naming Process 


There are three stages to the naming process. 


3.1. Right-To-Use 


First, a naming authority must establish the right-to-use for any 
name to be used, within the jurisdiction of the given naming 
authority. Names that are used in public are generally constrained 
by public laws. Names that are only used in private are a private 
matter. We are primarily concerned here with public names because 
these are the names that are most interesting to enter into public 
directories where we can search for them. 


There is a global governmental/civil/organizational infrastructure 
already in place to name and number things like people, cars, houses, 
buildings and streets; localities like populated places, cities, 
counties, states, and countries; organizations like businesses, 
schools, and governments; and other entities like computers, 
printers, ports, routers, processes, files, filesystems, networks, 
management domains, and so on. There are also naming (and numbering) 
authorities for various standards and for networks (e.g., ISO/IEC, 
CCITT, IANA) which depend on acceptance by their constituent 
communities for their authority. 
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This collective infrastructure is comprised of a very large number of 
authorities that we will call naming authorities. Naming authorities 
tend toward hierarchical organization. Parents have authority 
(granted by government) to choose the names of new-born children, the 
courts have authority to change a person’s name, car makers have 
authority to name the models of cars they build (within the limits of 
trademarking law), and they are obligated to assign unique serial 
numbers to each car. Cities assign names to their streets and 
districts, states assign city, county, and township names, and so on. 
State governments also assign names to "registered" organizations 
that operate under state charters, which in turn name their own 
suborganizations. Cities and Counties license businesses to use 
their chosen (unambiguous) names "in association with" the city and 
county names. Companies name and number the computers and 
communications devices they make and sell. There are many many name 
spaces, some of which are subordinate to others, and some of which 
are independent. 


Public names must be "registered" in some "public record" to record 
the fact of the assignment of the right-to-use to specific "owners." 
In general, this is to prevent collisions of the right-to-use 
assignments in public shared name spaces. For example, unique names 
given to corporations are registered by the state of incorporation. 
A request to use a new name for any corporation must not conflict 
with the name of any other corporation registered in the same state. 
The same applies for businesses licensed within cities and counties. 


Establishment of the right-to-use for a name is not a Directory 
Service. The right-to-use for a name is always derived from some 
other (non-directory) source of authority because of the legal 
aspects of intellectual property rights which are entirely outside 
the scope of directory service specifications. People and 
organizations attach great value to the names they are allowed to 
associate with their lives and businesses, and intellectual property 
law protects their interests with respect to these values. 


This is not to say that directory service designers and providers 
have no interest in the processes and procedures for establishment of 
the right-to-use for the names that will be entered into any 
directory. Indeed, without a supply of rightfully-usable names, 
there cannot be any directory. But, given an adequate supply of 
registered names, the directory service is not otherwise concerned. 


We should note here that some naming authorities must deal with name 
spaces that are shared among large communities (such as computer 
networks) in which collisions will occur among applicants for desired 
name assignments, while other name spaces (such as for given names of 
children in a family) are not shared outside the family. Sharing is 
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always a problem, which has led to trademarking laws, business 
license laws, and so on. Naming within organizations should be 
easier, because it is "in the family," so to speak. Hierarchical 
naming schemes facilitate distribution of naming authority. 


3.2. Registration 
Second, a name may be bound (as a value) to some object attribute. 


Given the right to use a name, a Naming Authority, such as a family 
which has an inherited surname and, more or less, has the right to 
use any names it pleases for its children’s given names, must bind 
selected names to selected object attributes (e.g., firstname=Einar). 
Note that this same name might also be used as the first name or 
middle name of other children, as long as each sequence of given 
names of each family member is distinguished (i.e., none are 
duplicates) within the family. Wise families do not bind the same 
sequence of given names to more than one child. Some avoid any 
multiple use of a single name. Some use generational qualifiers to 
prevent parent-child conflicts. 


The Internet Domain Name System (DNS) names top level domains which 
are then free (within some technical limits) to chose and bind names 
to entries which are subordinate to a given named domain, and so 
forth down the DNS name tree. The ISO/CCITT naming system serves the 
same purposes in other separate name spaces. 


3.3. Publication 


Third, after binding, a name must be advertised or published in some 
community if it is to be referenced by others. If it is not 
advertised or published, then no one can refer to it. 


This publication stage is what the Directory Service is all about. 
The Directory contains entries for "listed" names (or numbers) that 
are bound to the attributes of the entries in the directory DIT. 
Historically speaking, the directory business is a subclass of the 
publishing business, serving to dereference names into knowledge 
about what they stand for. 


It is important to keep in mind that a directory "listing entry" is 
not a "registration" unless a particular segment of the directory 
also just happens to be the authoritative master register of some 
naming authority. Registration and listing are very different 
service functions, though it is conceivable that they might be 
combined in a single DIT. 


For example, in the United States of America, each state name is 
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registered by the Congress by inclusion of the name in the 
legislation that "admits each State into the Union." Note however 
that the name is also then published in many places (such as on maps 
and in directories), while the master "register" is kept with the 
other original records of laws enacted by the Congress and signed by 
the President. Also, the name is then entered (listed) in many 
directories, in association with the name "The United States of 
America." And so on down the civil naming tree, with entities named 
in each state, etc. It is certainly not the case that the American 
National Standards Institute (ANSI) registers the names of the States 
in the United States of America! That right and duty is clearly 
reserved to the Government of the United States of America. 


On the other hand, in the Internet DNS, the act of inserting a given 
rightfully-usable name and address entry into a nameserver 
constitutes simultaneous registration and directory publication. 

4. Structuring Objects 
The first step in providing a civil naming infrastructure is to model 
the geographical/governmental entities which provide a basis for the 
assignment of public names. 

4.1. The National Level 
The nation is modeled with an object of class "country", subordinate 
to the root of the DIT, and has an RDN consisting of a single 
attribute value assertion: 

countryName= US 


The entry (minimally) contains these attributes: 


objectClass= country 
description= United States of America 


4.2. The Regional Level 


Within the nation, there are regions. Each region corresponds to a 
state or state-equivalent as recognized by the US Congress. The list 
of these is maintained in US FIPS 5. A sample entry from this FIPS 
document looks like this: 
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4+------------ 4+--------- 4+------- + 
| | State | State | 
FIPS-5 Numeric Alpha 
Name Code Code 
4------------ 4+--------- 4+------- + 
| | | | 
| California | 06 | CA | 
| | | | 
4+------------ 4+--------- 4+------- + 


Each region is modeled with an object of class 
"usStateOrEquivalent", which is defined thusly: 


usStateOrEquivalent OBJECT-CLASS 
SUBCLASS OF locality, nadfObject 
MUST CONTAIN { localityName, 
fipsStateNumericCode, 
fipsStateAlphaCode, 
stateOrProvinceName } 


Each entry is subordinate to "c=US", and has an RDN consisting 
of a single attribute value assertion: 


stateOrProvinceName= <FIPS-5 name> 


ENGi.7 


stateOrProvinceName= California 


Each entry (minimally) contains these attributes: 


objectClass= usStateOrEquivalent 

description= <official name of region> 
localityName= <FIPS-5 name> 

localityName= <FIPS-5 state alpha code> 
fipsStateAlphaCode= <FIPS-5 state alpha code> 
fipsStateNumericCode= <FIPS-5 state numeric code> 


e.g., 


objectClass= usStateOrEquivalent 
description= State of California 
localityName= California 
localityName= CA 
fipsStateAlphaCode= CA 
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fipsStateNumericCode= 06 
4.3. The Local Level 


Within each region, there are places. Each place corresponds to a 
county or county-equivalent as recognized by the regional government. 
The list of these is maintained in US FIPS 55 as a populated place 
with a five-digit numeric place code starting with "99." A sample 
entry from this FIPS document looks like this: 


t--------— paan t------— +----— sana +----— + 
| State | Place | State | | | 
| Numeric | Numeric | Alpha | | FIPS-55 | 
| Code | Code | Code | | Name | 
psss | nes t------— +----— tans pesans + 
06 99085 CA ons Santa Clara (County) 
| | | | | | | 
t--------- t--------- PARATE +----— tors PRESS + 


(Any parenthetical text in the FIPS-55 name is considered a 
"remark" about the place.) 


Each county is modeled with an object of class 
"usCountyOrEquivalent", which is defined thusly: 


usPlace OBJECT-CLASS 
SUBCLASS OF locality, nadfObject 
MUST CONTAIN { localityName, 
fipsPlaceNumericCode } 
usCountyOrEquivalent OBJECT-CLASS 
SUBCLASS OF usPlace 
MUST CONTAIN { fipsCountyNumericCode } 
Each entry is subordinate to the entry naming the region which 
contains the county, and has an RDN consisting of a single 
attribute value assertion: 
localityName= <FIPS-55 name without remarks> 


e.g., 


localityName= Santa Clara 


Each entry (minimally) contains these attributes: 
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objectClass= usCountyOrEquivalent 
fipsPlaceNumericCode= <FIPS-55 place numeric code> 
fipsCountyNumericCode= <last three digits of FIPS-55 
place code> 
stateOrProvinceName= <FIPS-55 state alpha code> 
stateOrProvinceName= <FIPS-5 corresponding name> 
description= <FIPS-55 name with remarks> 


e.g., 


objectClass= usCountyOrEquivalent 
fipsPlaceNumericCode= 99085 
fipsCountyNumericCode= 085 
stateOrProvinceName= California 
stateOrProvinceName= CA 
description= County of Santa Clara 


In addition, for each populated place named within the county, 
a non-distinguished "localityName" attribute value may be 
present to aid searching, e.g., 


localityName= Mountain View 
localityName= San Jose 


and so on. 
4.4. ADDMD Operators 


Also within the nation, there are public Directory service providers. 
Each service-provider corresponds to an ADDMD operator as recognized 
by the NADF. Each ADDMD operator is modeled with an object of class 
"nadfADDMD", which is defined thusly: 


nadfADDMD OBJECT-CLASS 
SUBCLASS OF nadfObject 
MUST CONTAIN { addmdName } 
MAY CONTAIN { organizationName, 
organizationalAttributeSet } 


Each entry is subordinate to "c=US", and has an RDN consisting of a 
single attribute value assertion: 


addmdName= <NADF registered name> 
e.g., 


addmdName= PSINet 
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Each entry (minimally) contains this attribute: 
objectClass= nadfADDMD 


The structure of the subtree below each "nadfADDMD" entry is a matter 


for that service-provider to establish. It must be emphasized that 
such entries are used to provide a "private" namespace for each 
service provider, as envisioned in NADF-128. This "nadfADDMD" entry 


is distinct from a service provider’s "organization" entry which 
would be used to contain organizational information about the service 
provider. 


4.5. Summary of Structuring Objects 


To summarize the naming architecture thus far: 


Pls T oe +----— fe Se oe eae +----— PSS SS SSS SSeS oS E + 
| Level |Elem | objectClass |Supr | RDN 

toss 5555 +----— tea a +----— tan + 
| root | o | | | | 
See þanna pimen +----— porien E + 
| international | 1 | country | 0 | countryName 

toss asa +----— tan +----— tans + 
| national | 2 | usStateOrEquivalent | 1 | stateOrProvinceName | 
| | 3 | nadfADDMD | 1 | addmdName 
E T +----— Hessen s sae E +----— prsa annsna + 
| regional | 4 | usCountyOrEquivalent| 2 | localityName | 
toa sss +----— tans +----— saan + 
| local | 5 | De a] | 
A +----— a E +----— sean + 


Or, in pictorial form: 
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root 
/ 
/ 
/ 
(===) 
(c=US) 
(S==5) 
‘alias 
/ \ 
farses essee sae / yr enen \ 
/ | \ 
for each state or (--=+-> ) / \ (--------- ) for 
state-equivalent (st=...) / \ (addmd=...) each 
(ara ) / \ (aene ) ADDMD 
i \ / \ 
/ \ /national \ 
/------------ / \ / listings \ 
/ Xo SSs3ShSeiasess= 
/ \ 
(----- ) for each /\ 
(l=...) county or Jv IN 
(----- ) county-equivalent / \ 
/ \ 
/regional\ 


| 
| 
| / listings \ 
| 


/ local \ 
/listings \ 
5. Entity Objects 
The next step in using the civil naming infrastructure is to model 
the entities which reside within the geographical/governmental 
structure. 
5.1. Organizations 
Organizations exist at several levels. 


5.1.1. Kinds of Organizations 


An organization is said to have national-standing if it is chartered 
(created and named) by the US Congress. An example of such an 
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organization might be a national laboratory. There is no other 
entity which is empowered by government to confer national-standing 
on organizations. However, ANSI maintains an alphanumeric nameform 
registration for organizations, and this will be used as the public 
directory service basis for conferring national-standing on private 
organizations. 


An organization is said to have regional-standing if it is chartered 
by the government of that region. An example of such an organization 
might be a public university. In addition, private organizations may 
achieve regional-standing by registering with the "Secretary of 
State" (or similar entity) within that region -- this is termed a 
"doing business as" (DBA) registration. 


NOTE: 


An organization may have a DBA registration in several states, 
even though it is incorporated in only one state. Where an 
organization registers itself is largely dependent on where it 
might choose to incorporate, and where it might choose to 
locate (and license) its business operations. 


For example, a large organization might have a DBA registration 
in most of the 50 states, and be incorporated in Delaware. For 
the purposes of this naming scheme, such an organization is 
said to have regional-standing in each state where it has a DBA 
registration. This DBA registration confers the sole right to 
use the DBA name in association with the named jurisdiction of 
the registration authority. 


An organization is said to have local-standing if it is chartered by 
a local government within that place. In addition, private 
organizations may achieve local-standing by registering with a 
"County Clerk" (or similar entity) within that place -- this is 
termed a "doing business as" (DBA) registration. Note that local- 
standing is somewhat ambiguous in that there may be multiple local 
governments contained within a county or county-equivalent. 
Depending on local government rules of incorporation and containment, 
registering with one entity may prevent others from registering that 
same name with other entities contained within that place. In order 
to avoid ambiguity, other distinguishing attributes, such as 
"streetAddress", may be needed to provide uniqueness. 


5.1.2. Modeling Organizations 
In the DIT, an organization is modeled with an object of 


class "organization". In addition, some combination of the 
following auxiliary object classes might also be used: 
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5 


tee 


(1) if an organization has national-standing derived from 
ANSI registration, then this is modeled by including in 
the entry an object class attribute value of 
"ansiOrgObject", which is defined thusly: 


ansiOrgObject OBJECT-CLASS 
SUBCLASS OF top 
MUST CONTAIN { ansiOrgNumericCode } 


(2) if an organization has national-standing (either in the 
US or some other nation), then it may be necessary to 
identify the country which corresponds to the registry 
which names the organization. This is modeled by 
including in the entry an object class attribute value 
of "nationalObject", which is defined thusly: 


nationalObject OBJECT-CLASS 
SUBCLASS OF top 
MUST CONTAIN { countryName } 


(3) if an organization has local-standing, then it may be 
necessary to identify the place in US FIPS 55 which 
corresponds to the registry which names the 
organization. This is modeled by including in the 
entry an object class attribute value of 
"fips5s50bject", which is defined thusly: 


fips550bject OBJECT-CLASS 
SUBCLASS OF top 
MUST CONTAIN { fipsPlaceNumericCode } 
MAY CONTAIN { stateOrProvinceName } 


Persons 


There are two kinds of entries for a person: organizational person 
and residential person. 


Definitions for an organizational person are a local matter to be 
decided by each organization. It is suggested that an organizational 
person be modeled with an object of class "organizationalPerson". 


Outside of organizations, persons exist only in a residential context. 
As such they always have local standing. For a given person, it 
should always be possible to identify the place in US FIPS 55 which 
corresponds to the "smallest" populated place where any person 
resides, and then use the code associated with that place to aid in 
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distinguishing the person. A residential person is modeled with an 
object of class "residentialPerson". In addition, since it may be 
necessary to identify the place in US FIPS 55 which corresponds 

to where the person resides, an object class attribute value 

of "fips550bject" may be present in entries corresponding to 
residential persons. 


6. Listing Entities 
The final step is to define how entities are listed within the 
context of the civil naming infrastructure. Note than an entity may 
have several listings (DNs) in different parts of the Directory. 


6.1. Organizations 


The RDN used when listing an organization depends on both the 
standing of the organization, and where the listing is to be placed: 


tan E A T AEA A AN EA + 
Pee SSeS E | Listing (RDN) under 
| Entity | c=us | c=US, st=X | c=US, st=X, l=Y | 
t--- 55-5555 +--------- t------------ t--- 55-555 + 
| national-standing | o | o, c=US | o, c=US 
piee e +--------- prendi e AS TA + 
| regional-standing | o, st=X | o | o 
A ER +--------- A EE ES + 
| .. (other region) | | -0y -sE=2 | o, st=Z 
E A T A E E S E o 55-55-55 + 
| local-standing | o, st=X | o, fips55 | o, fips55 | 
| | fips5s | | 
to - 5-5-5 +--------- 4------------ teers seses + 
| .. (other region) | | O, st=Z | O, st=Z, fips55 | 
| | | fipsss | | 
to E +--------- +------------ +---------------- + 
| foreign-standing | o, "See mre “le, To | 

c 

een Sees oe eee eee 


This scheme makes no requirements on the DIT structure within 
an organization. However, the following naming architecture 
is suggested: 
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4+---------------- 4+----- 4+---------------------- 4+---------- 4------------- + 
| Level |Elem | objectClass | Super | RDN | 
4+---------------- 4+----- 4+---------------------- 4+---------- 4+------------- + 
| listing | 11 | organization | 1,2,4 | | 
4---------------- 4+----- 4+---------------------- 4+---------- 4+------------- + 
| organizational | 12 | organizationalUnit | V1 712,13 | orgUnitName | 
| | 13 | locality | 11; 72, 13 | localityName | 
| | 14 | organizationalRole | 1145;12,13 | commonName | 
| | 15 | organizationalPerson | Tity 2513 | commonName | 
+---------------- 4+----- 4+---------------------- 4+---------- 4+------------- + 
| application | 16 | applicationProcess | 11,12,13 | commonName | 
| | 17 | nadfApplicationEntity| 16 | commonName | 
| | 18 | groupOfNames | 11,12,13 | commonName_ | 
| | 19 | ediUser | 11,12,13 | ediName | 
| | 20 | device | 11,12,13 | commonName | 
+---------------- 4+----- 4+---------------------- 4+---------- 4+------------- + 
Or, in pictorial form: 
(Tne ) 
(organization) 
(SSSssSesssee ) 
| 
| <------------------------------ + 
| | 
+---—> (organizationalUnit) ------- + 
| | 
+=-=>( locality) =s + 
| 
+--->(organizationalRole) 
| 
+---—> (organizationalPerson) 
| 
+---—> (applicationProcess) —-—-—>(nadfApplicationEntity) 
+---—> (groupOfNames) 
| 
+---> (ediUser) 
| 
+---> (device) 
6.2. Persons 


Listing organizational persons is a local matter to be decided by 
each organization. 


Residential persons are identified by the place where they reside, 


NADF 


[Page 16] 


RFC 


1255 


A Naming Scheme for c=US 


September 1991 


usually with a multi-valued RDN consisting of a "commonName" 


attribute value, 


and some other distinguished attribute value. 


Although an obvious choice is to use something like "postalCode" or 


"streetAddress", 


it should be noted that this information may be 


considered private. Hence, some other, distinguishing attribute 
value may be used -- possibly even a "serial number" attribute value 
which has no other purpose other than to give uniqueness. (It should 
be noted that an attribute of this kind is not helpful in regards to 
searching -- other attribute values containing meaningful information 
should be added to the entry and made available for public access, as 
an aid to selection.) 
The RDN used when listing residential persons depends on where the 
listing is to be placed: 
4+---------------------------------------- + 
sae a aie ee oh ee iia | Listing (RDN) under 
| Entity | “e208: | c=US, st=X | c=US, st=X, l=Y | 
4+------------------- 4+--------- +------------ +----------------- + 
| residential | Ĉi < | cn, | cn, , fipss5 | 
| person | st=X | fips55 | 
| | fips5s | | 
+------------------- +--------- 4+------------ +----------------- + 
| .. (other region) | | cn, . | cn, , St=Z 
| | | st=Z | fips55 | 
| | | fips55 | | 
+------------------- +--------- 4+------------ +----------------- + 
Note that listing of foreign persons is for further study 


7. 


In the examples which follow, 


Usage Examples 


the 


arbitrary value for an attribute type. 


Teds 


Organizations with National-Standing 


Suppose that the organization 


Lawrence Livermore National Laboratory 


"*"-character is used to 


denote any 


has national-standing by virtue of having been chartered by the US 


C 


has the right to list as any 


NADF 


ongress. 


(1) 


{xe 


national-listing: 


=US, 


(or all) 


According to the table in Section 6.1, 


of these names: 


this organization 
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o=Lawrence Livermore National Laboratory } 


(2) regional-listing: 
{ c=US, st=*, 
{ o=Lawrence Livermore National Laboratory, 
c=US } } 
(3) local-listing: 
{ c=US, st=*, 1=*, 
{ o=Lawrence Livermore National Laboratory, 
c=US } } 
Suppose that the organization 
Performance Systems International, Inc. 
has national-standing by virtue of having an alphanumeric nameform in 
the ANSI registry. According to the table in Section 6.1, this 
organization has the right to list as any (or all) of these names: 
(1) national-listing: 
{ c=US, o=Performance Systems International } 
(2) regional-listing: 
{ c=US, st=*, 
{ o=Performance Systems International, c=US } } 


(3) local-listing: 


{ c=US, st=*, 1=*, 
{ o=Performance Systems International, c=US } } 


7.2. Organizations with Regional-Standing 
Suppose that the organization 
Network Management Associates, Inc. 
has regional-standing by virtue of having a DBA registration with the 


Secretary of State for the State of California. According to the 
table in Section 6.1, this organization has the right to list as any 
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(or all) of these names: 
(1) national-listing: 
{ c=US, 
{ o=Network Management Associates, 
st=California } } 
(2) regional-listing: 
{ c=US, st=California, 
o=Network Management Associates } 
(3) local-listing: 


{ c=US, st=California, l1=*, 
o=Network Management Associates } 


Further, in some state other than California, this 
organization might also list as: 


(1) regional-listing: 
{ c=US, st=*, 
{ o=Network Management Associates, 
st=California } } 
(2) local-listing: 
{ c=US, st=*, 1=*, 
{ o=Network Management Associates, 
st=California } } 
7.3. Organizations with Local-Standing 
Suppose that the tavern and eatery 


St. James Infirmary 


has local-standing by virtue of having a DBA registration with the 
City Clerk for the City of Mountain View in the State of California. 
According to the table in Section 6.1, this organization has the 
right to list as any (or all) of these names: 


(1) national-listing: 
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{ c=US, 
{ o=St. James Infirmary, st=California, 
fips55=49670 } } 
(2) regional-listing: 
{ c=US, st=California, 
{ o=St. James Infirmary, fips55=49670 } } 
(3) local-listing: 


{ c=US, st=California, l1=*, 
{ o=St. James Infirmary, fips55=49670 } } 


Further, in some state other than California, this 
organization might also list as: 


(1) regional-listing: 
{ c=US, st=*, 
{ o=St. James Infirmary, st=California, 
fips55=49670 } } 
(2) local-listing: 
{ c=US, st=*, 1=*, 
{ o=St. James Infirmary, st=California, 
fips55=49670 } } 
7.4. Organizations with Foreign-Standing 
Suppose that the five-star restaurant 
Erik’s Fisk 
has foreign-standing by virtue of having a DBA registration 
throughout Sweden. According to the table in Section 6.1, this 
organization has the right to list as any (or all) of these names: 


(1) national-listing: 


{ c=US, 
{ o=Erik’s Fisk, c=SE } } 
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(2) regional-listing: 
{ c=US, st=*, 
{ o=Erik’s Fisk, c=SE } } 
(3) local-listing: 


{ c=US, st=*, 1=*, 
{ o=Erik’s Fisk, c=SE } } 


7.5. Persons 
Suppose that the person 
Marshall T. Rose 
residing in the City of Mountain View in the State of California, 
wishes to be listed in the Directory. According to the table in 
Section 6.2, this person might be listed as any of these names: 
(1) national-listing: 
{ c=US, 
{ cn=Marshall T. Rose, postalCode=94043-2112, 
st=California, fips55=49670 } } 
(2) regional-listing: 
{ c=US, st=California, 
{ cn=Marshall T. Rose, postalCode=94043-2112, 
fips55=49670 } } 


(3) local-listing: 


{ c=US, st=California, 1=Santa Clara, 
{ cn=Marshall T. Rose, postalCode=94043-2112 } } 


Further, in some state other than California, this person 
might also list as: 


(1) regional-listing: 
{ c=US, st=*, 


{ cn=Marshall T. Rose, postalCode=94043-2112, 
st=California, fips55=49670 } } 
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(2) local-listing: 


{ c=US, st=*, 1=*, 
{ cn=Marshall T. Rose, postalCode=94043-2112, 
st=California, fips55=49670 } } 
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Appendix A: Revision History of this Scheme 


The first version of this scheme (NADF-71) was contributed to the 
North American Directory Forum at its November 27-30, 1990 meeting. 
The (mis)features were: 


(1) Because of the lack of confidence in ANSI registration 
procedures, it was proposed that the US trademarks be 
used as the basis for RDNs of organizations with 
national-standing. 

This proved unworkable since the same trademark may be 
issued to different organizations in different 
industries. 


(2) There was no pre-existing registry used for populated 
places. 
This proved unworkable since the effort to define a new 
registry is problematic. 


The second version of this scheme was contributed to the ANSI 
Registration Authority Committee at its January 30, 1991 meeting, and 
the IETF OSI Directory Services Working Group at its February 12-13, 
1991 meeting. The (mis) features were: 
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(1) The ANSI numeric name form registry was used as the 
basis for RDNs of organizations with national 
standings. 

(2) The FIPS 5 state numeric code was used as the basis for 


RDNs of states and state-equivalents. 


(3) The FIPS 55 place numeric code was used as the basis 
for RDNs of populated places. 


The choice of numeric rather than alphanumeric name forms was 
unpopular, but was motivated by the desire to avoid using the ANSI 
alphanumeric name form registry, which was perceived as unstable. 


The third version of this scheme was contributed to US State 
Department Study Group D’s MHS-MD subcommittee at its March 7-8 1991 
meeting. That version used alphanumeric name forms for all objects, 
under the perception that the ANSI alphanumeric name form registry 
will prove stable. If the ANSI alphanumeric name form registry 
proves unstable, then two alternatives are possible: 


(1) disallow organizations with national-standing in the US 
portion of the DIT; or, 


(2) use the ANSI numeric name form registry instead. 


Hopefully neither of these two undesirable alternatives will prove 
necessary. 


The fourth version of this scheme (NADF-103) was contributed to the 
NADF at its March 18-22, 1991 meeting. This version introduced the 
notion of organizations with regional standing being listed at the 

national level through the use of alias names and multi-valued RDNs. 


The fifth version of this scheme (NADF-123) was produced at the NADF 
meeting (and also published in the Internet community as RFC1212). 
This version generalized the listing concept by introducing the 
notion of optimized civil naming. Further, the document was edited 
to clearly note the different naming sub-structures and the relation 
between them. 


The sixth version of this scheme (NADF-143) was contributed to the 
NADF before its July 9-12, 1991 meeting, and was edited to reflect 
comments received from the Internet and other communities. The 
changes were: 


(1) The schema definitions were removed from Appendix A and 
placed in a separate document, NADF-132. In NADF-132: 
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the prefix object-identifier was changed (the original 
assignment was in error); and, the definition of a 
"nadfADDMD" object was considerably expanded. 


(2) States and state-equivalents are now named using 
attribute values of "stateOrProvinceName". 


(3) Populated places now correspond to counties, though 
FIPS 55 is still used extensively. 


(4) The text of this document was reworked to more clearly 
distinguish between registration and listing. 


(5) The "foreignOrganization" and "fips550bject" object 
classes were added. 


The seventh version of this scheme (NADF-166) was produced at 
the NADF meeting. It made a few changes: 


(1) It was noted that organizations with local standing may 
need additional distinguishing attributes when listing. 


(2) The "usOrganization" object class was removed and 
replaced with the auxiliary object class 
"ansiOrgObject". 


(3) The "foreignOrganization" object class was removed and 
replaced with the auxiliary object class 
"nationalObject". This may be used when listing any 
organization of national standing (regardless of 
whether that organization is US-based). For example, 
an organization with US national-standing would need 
this when being listed at the regional or local level. 


(4) Figures corresponding to the DIT structures were added, 
along with some minor additional text in the usage 
examples. 

(5) The Acknowledgements section, long out of date, was 
removed. 


The eighth (current) version of this scheme was produced after 
the NADF meeting. It corrects a few typographical errors. 
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Security Considerations 

Security issues are not discussed in this memo. 
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